Fixes race condition getting IPv4 TCP table on Windows. #880
Conversation
|
This looks reasonable. |
|
OK, thanks, will update shortly :-) |
|
OK. I updated the code to affect TCP IPv6, UDP IPv4 and UDP Ipv6 too. I also updated Tests are not passing now, still needs a bit of work. |
|
Added the code to release the GIL, as requested :-) |
|
@giampaolo I think I addressed everything you asked. Let me know if this PR needs more work :-) |
|
Sorry I'm busy and still didn't have time to look at this but I promise I will (likely during the week end) |
|
Merged. Thanks. |
|
Thanks for merging this! |
|
Thanks for the PR. ;) |
We've been getting rather frequent cases where the
psutil.Process().connections()returns an empty list on Windows when we know for a fact that there are open TCP connections on the machine.We traced down the problem to the fact that there is a race condition in the
GetExtendedTCPTable()API: since we call it twice (once to get the size, once to read the data), it happends that new connections open between the two calls to theGetExtendedTCPTable()function and the table size is too small on the 2nd call.The solution to this is to call the function in a loop and repeat until we manage to successfully read the data.
I couldn't run the tests on my machine, so I'm sending this as a preliminary patch. I think the other calls (e.g. for IPv6, and probably UDP) also need this too. Maybe some refactoring could help move this logic in common somewhere.